Computer-readable markup languages predate the World Wide Web (“WWW”), but the WWW was the initial driver for the increased popularity of markup languages—starting with presentation-oriented markup languages, like the HyperText Markup Language (“HTML”), and eventually leading to the widespread use of content-oriented markup languages, like the eXtensible Markup Language (“XML”). One such content-oriented markup language is the eXtensible Business Reporting Language (“XBRL”). XBRL allows businesses to communicate efficiently and accurately with each other, with investors, and with regulatory agencies. Using XBRL, a company can associate tags with data (e.g., values) in the company's financial statements. This process, commonly called “tagging,” supplies additional information about the data being tagged (sometimes referred to as “metadata”). The information can then be searched, reorganized for analytical purposes, and processed into human readable formats such as graphs, spreadsheets, or other tabular renderings. XBRL can be integrated with HyperText Markup Language in the form of inline XBRL (“iXBRL”).
Reports (e.g., financial statements) that publicly-held companies file with the United States Securities and Exchange Commission (“SEC”), are required to be tagged with metadata that conforms to XBRL. XBRL tagging is therefore a key part of the financial statement production process. The SEC requirements, covering interactive data reporting using XBRL, provide prescribed ways to represent data and its metadata, including rules about how the two should be associated.
Among the metadata represented in an XBRL taxonomy is a concept-based calculation relationship, which defines an arithmetic relationship between specified, appropriate metadata “tags.” For example, an taxonomy (which is typically set forth in one or more sections of XML and/or XML Linking language (“XLink”)) may contain a calculation relationship asserting that a value tagged with the concept “Assets” (“fact Assets”) should equal the sum of the values tagged with concepts “Current Assets” and “Noncurrent Assets,” respectively. Tagged values (“facts”) whose concept tags are referenced in a calculation relationship can be validated by an XBRL processor (software that is capable of reading and interpreting XBRL). For example, given facts for Assets, Current Assets, and Noncurrent Assets, and the example relationship above, an XBRL processor can validate the fact Assets by verifying that its value is consistent with the summation of facts Current Assets and Noncurrent Assets. The result of this validation is either a confirmation that fact Assets is “consistent” with the processor-calculated value, or that fact Assets is “inconsistent” with the processor-calculated value. Detection of inconsistencies prior to delivery of XBRL-formatted statements is an important step in improving the accuracy of these statements, thus reducing the chance that a restatement of information and correction is required at a later date. Further, data consumers (e.g., shareholders, regulatory agencies, or members of the public) also benefit from being able to confirm these same consistencies.
Currently, there are semantically valid arithmetic relationships and/or combinations of XBRL facts that are often used in financial report, but which currently cannot be represented in a concept-based calculation relationship in the most recently-adopted version of XBRL. In effect, there is a gap between what kinds of calculation relationships XBRL covers and what kinds of relationships users of XBRL need it to cover. Thus, users of XBRL currently have only partial risk mitigation to the problem of calculation inconsistencies.